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(57) ABSTRACT 

Information is stored that reflects the existence of relation- 
ships between identified parties with respect to use of the 
digital facility. A predetermined type of interaction of the 
parties is permitted) via the electronic communication 
medium with respect to the digital facility if the stored 
information reflects the existence of relationships between 
them. 
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MANAGING RELATIONSHIPS OF PARTIES 
INTERACTING ON A NETWORK 

BACKGROUND 

This invention relates to managing relationships of parties 
interacting on a network. 

A party that has information to be made available to other 
parties with which it has or wishes to have relationships can 
disseminate the information to the other parties on a web site 
using a web server that is accessible by web browsers. 

In a commercial context, for example, a manufacturer 
may try to increase sales of its products or services by giving 
better information and support to resellers or other compa- 
nies that are in the chain of distribution between the manu- 
facturer and end customers. On the other hand, the manu- 
facturer may want to screen a particular type of customer 
from having access to information that is not targeted to that 
type of customer. 

Access to the information by different parties can be 
regulated by firewalls, by password techniques, and in other 
ways. 

SUMMARY 

In general* in one aspect of the invention, at least one 
digital facility is made available via an electronic commu- 
nication medium. Information is stored that reflects the 
existence of relationships between identified parties with 
respect to use of the digital facility. A predetermined type of 
interaction of the parties is permitted via the electronic 
communication medium with respect to the digital facility if 
the stored information reflects the existence of relationships 
between them. 

Implementations of the invention may include one or 
more of the following features. The stored information 
identifies the nature of interaction permitted or precluded 
between identified parties with respect to use of the digital 
facility. The nature of interaction includes one of the parties 
being exposed to the existence of another of the parties in 
connection with using the digital facility. The existence of 
the other of the parties is made apparent by inclusion of the 
other of the parties in a displayed list of parties with whom 
interaction is permitted, the displayed list being determined 
by the stored relationship information. The interaction of 
parties via the electronic communication medium is gov- 
erned by permissions defined with respect to the relation- 
ships. The permissions include a permission to be aware of 
the existence of specified other parties. The parties include 
individuals, groups of individuals, and commercial enter- 
prises. The permitted interaction includes working together 
on a task, delivery of content, or one party accessing 
specified data that is associated with another one of the 
parties. Individuals may have a relationship only if respec- 
tive institutions with which they are affiliated have a rela- 
tionship. The stored information is created and controlled by 
parties only in accordance with permissions belonging to 
those parties. The predetermined types of interactions that 
are permitted and precluded are defined in stored permis- 
sions. 

Among the advantages of the invention are one or more 
of the following. The system enables the portal-providing 
company and other companies interacting through the portal 
to make better use of their marketing and sales people and 
resources. The portal-providing company and other compa- 
nies interacting through the portal can use the system to 
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motivate their selling partners to achieve higher sales. The 
impact and reach of the portal-providing company's direct 
sales people and the front-line teams of other companies 
interacting through the portal can be improved. Selling 

5 partners and customers develop a greater awareness of the 
portal-providing company and other companies interacting 
through the portal. Selling partners are given enhanced 
marketing capabilities. The portal-providing company and 
other companies interacting through the portal can present a 

10 single coordinated image to selling partners and customers 
while providing custom experiences for individual users. 
The system also enables improvement of the performance of 
many other business processes that occur between and 
within companies. These improvements may take the form 

15 of reduction in the time required to execute. The system can 
improve the performance of interactions with a company's 
suppliers and vendors. It can also improve the performance 
of processes that occur after a business transaction, includ- 
ing the execution of implementation projects, service, and 

20 support. And it can improve the performance of a wide range 
of internal company processes. 

Other advantages and features will become apparent from 
the following description and from the claims. 

25 DESCRIPTION 

FIG. 1 is a block diagram of a relationship management 
system. 

FIG. 2 is a schematic diagram of examples of the granting 
30 of perform and grant permissions. 

FIG. 3 is an illustration of aggregate permissions. 

OVERVIEW 

35 As shown in FIG. 1, a portal-providing company 20 can 
use relationship portal software 21 running on its web server 
22 to leverage the value of information stored in its business 
database 24. Software 21 can be used to regulate relation- 
ships that the portal-providing company has with other 

^ parties 26, including the portal-providing company's direct 
customers 28, other companies 30 along a chain of distri- 
bution 32, end customers 34, and marketing partners 36. The 
software can also be used to regulate relationships that 
parties in the chain other than the portal-providing company 

45 have with each other (e.g., a relationship between a direct 
customer and an end customer), at least to the extent that the 
relationship involves the portal-providing 
company ' information. 
The business database 24 can be an existing database or 

50 a newly created database. Typically the business database 
would include information about products or services, 
prices, terms, availability, marketing plans, historical and 
projected sales, and any other information that would be 
useful in facilitating the relationships among the companies 

55 and employees who are authorized to use the system. 

The regulation of relationships by software 21 can include 
control of which information of the various companies that 
participate in the portal environment is made available to 
which other companies and to which employees of those 

60 companies. The regulation can also include control of how 
the information is presented to the employees of the com- 
panies to enable the delivery of different "experiences" to 
different companies and their employees. In that way, the 
software 21 and the web server 22 can provide a personal 

65 relationship portal 27 that can have custom appearances and 
behaviors for each of the employees that communicates with 
the web server through a web browser. Each employee of 
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any of the companies can get access to the web server from the rights of users and companies with respect to informa- 

anywhere in the world through a network 40 that could be, tion and functions that are made available by the portal 

for example, the Interact, an Intranet, a local area or wide applications. Permissions are granted by users of the system 

area network, a dial up connection, or any other arrangement in ways (described below) that enable the development of a 

that allows communication between the employee's web 5 rich, distributed fabric of personal relationship portals for a 

browser and the network. range of users and companies who are in the constellation of 

Software 21 provides two main functions: configuration interest of the portal-providing company. All of the personal 
of me software to serve a portal-providing company and its relationship portals are implemented from the portal- 
relationship partners, and run-time operation of the software providing company's server, but the particular permissions 
to provide the personal relationship portals to employees of 10 and preferences of any one of the personal relationship 
the companies. portals are not necessarily fully controlled by the portal- 

Thc configuration function includes identifying and ere- providing company. Rather the ability to control them is 

ating profiles for companies and employees of companies distributed so that other companies within the constellation 

who will have access to the system, and defining the and other users in those companies may be able to influence 

relationships among the companies and employees, the the configurations and permissions associated with some of 

rights that each company and employee will have to use the the portals. How this is done will be explained more fully 

system, and the preferences of each employee that together below. 

establish the nature and content of each employee's personal Preferences define how the user wishes to receive the 

relationship portal. The configuration information is kept in information and services made available by the portal appli- 

a portal management database 23 associated with software ^ cations. Permissions and preferences are similar in that they 

21. are unique named objects defined by a portal application. 

Run-time operation includes conveying each of the per- Actual permission values for a user represent specific access 

son a I relationship portals to web browsers in accordance rights to application functionality, whereas specific prefer- 

with the configuration and information contained in the ence values influence application behavior, 

portal management database 23 and in the business database ^ USER PRO FlLES AND COMPANY PROFILES 
24. In addition to providing information, each personal 

relationship portal can provide functions and services to the H may be required that a profile for a company to which 

employee using the browser. a belong* must exist before a profile for the user can be 

A wide variety of hardware and software can be used to created, 

implement the web server 22 The relationship portal soft- 30 A company profile can include demographic data; lists of 

ware 21 and the portal management database 23 may be other companies with which the company has a relationship; 

based on an appropriate set of platforms that can include m some implementations a list of the maximum permissions 

Microsoft Transaction Server (MTS) and Microsoft Internet ^ «*crs *t the company can be given in creating or 

Information Server (IIS). The relationship portal software managing the profiles of other users and companies; and a 

may take advantage of typical web software capabilities 3S °* other users who are allowed to manage the profile of 

including Active Server Pages (ASP), Component Object company. A user profile may include demographic data; 

Model (COM) objects, Java, Extensible Markup Language permissions given to the user to create and manage the 

(XML), and ActiveX Database Objects (ADO). In one profiles of other users and companies; a list of permissions 

implementation, the relationship management software given to me user wim resrject to omer objects m the system; 

comprises a Java class library that implements a suite of ^ * list of preferences of the user for his personal relationship 

portal applications 29. The portal applications provide both P^tal; and a list of other users who are allowed to manage 

the configuration capabilities and run-time features of the mc profile of the user. 

system. Other platforms may be used in implementations of The user profile contains a listing of permissions to which 
the invention, including BEA Systems WebLogic Server, the user has some level of perform permission (defined 
IBM WebSphere Application Server, Java Server Pages 45 below). In one implementation, the maximum permissions 
(JSP), Enterprise Java Beans (EJB) and Java Database available to a user are limited by the permissions assigned to 
Connection (JDBC). me user's company. Once permissions are assigned to a user, 
The relationship portal software may include a generic company permissions are not consulted in order to 
schema for the portal management database 23. The data- determine what facilities are available to the user. However, 
base initiaUy includes seeded descriptive data in the form of 50 whcn company permissions arc removed, they arc also 
query scripts. The Java class library can "talk to" the removed from all of its employees, 
database, i.e., gather data from the database, manipulate the Once a user has been created, the "belongs to" relation- 
data, and store data in the database. The relationship portal ship of that user to his company cannot be changed except 
software includes HTML web pages and/or can include to the extent that the user wanting to make the change has 
ASPs that can communicate with the Java class libraries 55 permission to do so. 

using COM communications. The server distributes the A company profile can be created and exist independently 

resulting web pages in the form of personal relationship of any other company or user. This conveniently enables 

portals to the user browsers. company profiles to be created and to exist without users 

The relationship portal software handles two types of until a later time, 

parties: users and companies. A user is a person who is 60 For users who are at the end of a relationship chain (e.g., 

employed by or is otherwise associated with ("belongs to") who don't work for a company), such as shareholders, an 

a company. Information about users, groups of users, and artificial company profile in the name of, e.g., 

companies is generated as part of the configuration process. "Shareholders", could be created. The Shareholders com- 

The information is stored and maintained as profiles in pany would be simply a grouping mechanism for those 

tables in the portal management database 23. 65 users. 

The profiles include two important classes of information, Each user profile or company profile has a "profile 

called permissions and preferences. The permissions define manager". The profile manager is the user who has the 
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permission to change settings and possibly delete the profile. Portal Builder displays web pages to present and collect 

These abilities are expressed in the "modify user profile" the demographic data about users and the companies they 

and "remove user profile" permissions. One or more aggre- work for and to establish user permissions and preferences 

gate permissions (discussed below) may be configured to set defined by portal applications. As a portal application, Portal 

the manager permissions. 5 Builder defines its own set of permissions that control how 

A person who has permission to, and who does initially »* can be used and that it also manages when configuring a 

creates a user is automatically the profile manager for the personal relationship portal. 

new user. The profile manager will have both perform and A portal application uses the Portal Builder to define 

grant permissions of the aggregate permissions. The rela- permissions that must exist for a user to make use of the 

tionship between the permission to create an object and the H> application. The Portal Builder assumes the responsibility 

permission to manage an object is configurable. The concept for gathering that information on behalf of the other portal, 

of managing an object derives from aggregate permissions, applications. 

which are discussed below. Aggregate permissions often The table set forth in appendix A lists the fundamental 

include fundamental permissions to view, modify and delete components of the profile service of the Portal Builder in one 

an object, which are aggregated into what is effectively a 15 implementation. A user interacts with the Portal Builder 

right to manage that object. through a series of web pages that walk the user through a 

User profiles are created by other users. In another process. The screens associated with the web pages for one 

implementation, users are given permission to manage all implementation are listed in the table of Appendix B. 

users at particular companies and there are not user man- PPPMI<KIONS 

agement permissions. A company profile is created by a user 20 rtutMiaaiuwa 

The user who sets up a company profile automatically The ability of a user to access the functions and informa- 

becomes a manager of that company's profile. tion available through the relationship portal software 21 is 

Some users may be allowed to create companies of certain governed by a system of permissions. The experience of a 

types. Company types are themselves configurable and may ^ user on his personal relationship portal is determined in large 

differ from one portal installation to another. The users part by the permissions that he has. The permissioning 

automatically become managers of the companies they architecture is highly adaptable and highly granular. The 

create. Other users may be given permission to manage identity and scope of the permissions to which a user is 

certain company profiles but not to create any. These com- entitled are determined by other users and are restricted by 

pany managers can change demographic data freely, but they ^ a set of rules that limit the ability of a user to grant 

can only change permissions to which they themselves have permissions to other users. If carefully constructed, the 

the grantright. fabric enables a portal-providing company, and other com- 
panies who participate in the system, to control the dissemi- 

GROUPS nation of information and the access to services in a way that 

Permissions may also be assigned to users through the 3S enhances and facilitates their relationships with parties who 

mcchanismofgroups.AgroupisacoUcctionofusers.Auser can advance their interests. Conversely, dissemmalion of 

with a grant right to a permission may give that permission information and the access to services can be restricted for 

to a group just as he or she would give it to an individual P**"* who can injure the interests of the portal-providing 

user. Once the permission has been given to a group it is company. 

automatically conferred on all members of that group. Users 40 A permission specifies the right that a user may be given 

may become members of groups in two ways. First, a user to access the functions of a portal application. Roughly 

who has the permission to manage a group can designate speaking, a permission is a capability to do "something" 

members individually. Second, a user who has the permis- (through the medium of the portal application), perhaps with 

sion to manage a group can specify that users with a certain respect to "something else". For example, the something 

demographic profile will automatically be members of that A5 which a permission enables may be to change a profile of a 

group. Any user who becomes a member of a group imme- company, or to modify a user profile, or to create a user, or 

diately acquires all the permissions that have been given to create a company of a particular type. A permission has an 

the group. The use of groups simplifies administration of argument, which refers to the "something else" to which the 

permissions by enabling a large number of permissions to capability pertains. The argument can refer to any object in 

easily be assigned by putting users in just a few groups. 50 the system such as a company or a piece of data. 

_ Each portal application 29 defines permissions that a user 

PORTAL BUILDER APPLICATION musl ha Vc b order to access the application or specific 

The configuration functions are provided by one of the functions of the application. The application defines the 

portal applications, called "Portal Builder". Portal Builder arguments of any permissions that it defines. Auser may not 

enables users to view, modify, remove, and create user 55 access features and functions of portal applications unless 

profiles and company profiles and in that manner to set the the user has a "perform" permission (defined below) with 

stage for personal relationship portals that are made avail- respect to the feature or function. At run-time, the portal 

able at run-time to users of the system. Each user has access application uses permission information maintained by the 

to Portal Builder to view and modify portions of his own Portal Builder to determine whether and how to respond to 

user profile. This capability is limited by the user's permis- 60 a user request. 

sions with respect to him. The definitions of possible permissions arc stored in a 
Specific functions of the Portal Builder, such as creating, permission definition table in the portal management data- 
modifying and removing user profiles, are available to a user base. The actual specific permissions associated with a given 
only if the user has permission to access those functions. user or company are stored as values in a party permission 
Typically those functions are used by individuals identified 65 table of the portal database. Portal applications that are 
as relationship managers to configure personal relationship invoked by a user consult the party permission table to 
portals for customers of their companies. determine if a user has a needed permission. 
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A permission may (but need not) have an argument, a 
value specifying an entity to which the permission applies. 
For example, a permission to create a company carries an 
argument that identifies the type of company. 

In one implementation, when the database table of per- 
missions is initially created, there is one set of permissions 
granted to one person called the system administrator. These 
permissions give the system administrator the right to create 
and modify companies of all types. In this implementation, 
the system administrator company (a fake company whose 
sole employee is the system administrator) is also given this 
permission. The system administrator and company are also 
given other global permissions with respect to other appli- 
cations. In another implementation, the system administrator 
is given a "wildcard" argument value to all permissions, 
which translates to the complete list of possible objects for 
each permission. 

COMPANY PERMISSIONS 

In some implementations, permissions apply both to 
companies to which a user belongs and to the user himself. 
Although only individuals are direct users of relationship 
portals, permissions may be recorded for companies to 
which the people belong to enable further regulation of the 
permission fabric. The permissions that can be given to a 
user are constrained by both the permissions of the company 
to which he belongs and by the permissions of the user who 
is granting the permissions to the recipient. The permissions 
of a company (also called guard settings) define the maxi- 
mum amount of permissions that a user who belongs to the 
company can be given. Auser,creating a new company asks, 
"What are the maximum amount of permissions that any 
user at this company may need?" and then gives the com- 
pany those permissions. If a user who belongs to that 
company later needs more permissions, new company per- 
missions must be added before the user can be given the 
permissions. 

PERFORM PERMISSIONS; GRANT 
PERMISSIONS; CASCADING PERMISSIONS 

A permission may specify either or both of two aspects of 
permission: a perform right and a grant right. The perform 
right of a permission (the "perform permission") gives a user 
the right to perform a specific function offered by a portal 
application. As suggested in the example shown in FIG. 2, 
the grant right of a pennission (the "grant pennission") gives 
a user the right to grant to other users the perform permission 
and the grant permission with respect to the application 
functionality associated with the permission. The grant and 
perform permissions arc represented by flags in the profiles 
stored in the portal management database. As shown in FIG. 
2, user A's grant permission 100 enables user A to grant 
perform permission 102 to user B and grant permission and 
perform permission 104 to user A user (such as user B) who 
does not have the grant permission cannot modify the 
perform permission for any other user, either to add it or to 
remove it. A user who has the grant permission may give the 
perform permission or the grant permission or both to 
another user. In this way, the "cascading" of permissions can 
continue without limit as long as each user gives grant 
permissions to next users in the cascade. In FIG. 2, user C 
can give grant permission 106 to user E who works in 
another company and user E can then give perform permis- 
sions 108, 110, 112 to three other users F, G, and H in three 
other companies. 

The result can be cascading tiers of personal relationship 
portals. For example, a selling partner or customer of the 
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portal-providing company can create personalized branded 
web sites for its customers or downstream partners and can 
reuse information and services available on the portal- 
providing company's portal. 

5 A user (such as user A) can have the grant permission 
without having the perform permission. This is natural, 
because a user may be responsible for managing the per- 
missions of users who have responsibilities that the manager 
himself does not have. For example, a sales person may be 

1° responsible for- managing the permissions of all users at an 
account. One of those users may be a lawyer. The sales 
person must be able to set up the lawyer's permissions but 
should not have access to the legal content. Although it 
would be possible for a malicious user to create a fake user 

15 and log in as the fake user to get access to functions not 
meant for him, that act would create an easily traceable trail. 

CASCADING PERMISSIONS AND USER/ 
COMPANY RELATIONSHIPS 

20 The link between cascading permissions and the relation- 
ships of users to companies is suggested by what happens to 
user permissions when a change occurs for the company to 
which the user belongs. 

23 For example, suppose that a company is initially defined 
in the portal management database as a "Tier I" company 
(e.g., a large or highly profitable company). The portal- 
providing company wishes to permit Her I companies to 
have only the ability to submit questions to an Ask the 

3Q Expert application, and companies of all other Tiers to have 
only the ability to read the questions and answers. 

If the Her I company becomes less profitable and falls 
beneath the Tier I threshold, the company and its users will 
need to be switched into the Tier II category. The effect of 

35 the switch should be to remove from users who belong to the 
company the ability to submit questions to Ask the Expert 
and leave them only with the ability to read. 

Conversely, suppose that a company is initially recorded 
as a "Tier IP company. Because the portal-providing com- 

40 pany only wants Her I companies to have the ability to 
submit questions to the Ask the Expert portal application 
while giving all other Hers only the ability to read, this 
company may only read postings to Ask the Expert. 
If the company becomes more profitable, the company 

45 can be switched to Her I in the database to give its users the 
ability to submit questions to Ask the Expert. 

When additional permissions are added to a company, the 
user who is making the change to the company record can 
pick and choose manually which users of the company 

50 should have their permissions changed. When permissions 
are removed from a company, all users belonging to that 
company should lose the removed permission. 

FUNDAMENTAL PERMISSIONS 

55 Examples of basic permissions (called "fundamental 
permissions 0 ) that a portal application might define and 
invoke are shown in the table contained in Appendix C. 
Detailed explanations of four possible permissions follow. 

60 Create Company — This permission gives the user the 
ability to create new company profiles in the portal man- 
agement database. A user who has this permission is auto- 
matically given the remaining permissions, described below, 
for a company that he creates. 

65 Modify Company — This permission gives the user the 
ability to modify the permissions of existing companies. The 
permission includes the permission to modify the perm is- 
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sions of all users belonging to that company and to create 
new user records belonging to that company. The argument 
of this permission is the list of companies that the user may 
be allowed to modify. The grant permission of this permis- 
sion specifies which companies the user can give other users 
the ability to modify. 

Create Company User — This permission gives a user the 
ability to create other users. The argument of this permission 
is the list of companies at which this user may create users. 
The grant component of the permission specifies the com- 
panies at which the current user may enable other users to 
create users. 

Modify Company User — This permission enables a user 
to modify the permissions of specific users. The argument of 
this permission is the list of companies at which this user 
may modify users. The grant component of the permission 
specifies the companies at which the current user may enable 
other users to modify users. 

AGGREGATE PERMISSIONS 

Because the fundamental permissions are so granular, it is 
also convenient to provide an "aggregate" permission capa- 
bility. As shown in FIG. 3, an aggregate permission 1, 2, 3, 
or 4 is denned by the portal application A, B, or C that may 
invoke the permission at run -time. An aggregate permission 
is not a permission by itself but only a defined aggregation 
of permissions. The fundamental permission definitions are 
stored in one table in the portal management database. The 
aggregate permission definitions are stored in another table, 
and the mappings between the aggregate permissions and 
the fundamental permissions are stored in a third table. The 
permission values, the actual settings for a person or 
company, are stored in yet another table. This table includes 
the fundamental permission value and the aggregate it is 
associated with. The reason for this is that in the case of 
overlapping aggregates (see below), the same fundamental 
permission may have different values. The rule is that the 
value with the greatest rights wins. When one of the over- 
lapping aggregate permission values is removed, the funda- 
mental permission values associated with the other overlap- 
ping aggregate permission is retained. 

Every aggregate permission is associated with one portal 
application. The aggregate permission 1 incorporates per- 
missions A-W, A-X, and so on, in each case only for the 
portal application with which it is associated. A portal 
application C, for example, may be associated with more 
than one defined aggregate permission 3 and 4. Aggregate 
permissions may overlap, meaning that they map to the same 
underlying, fundamental, permissions. 

Users of the Portal Builder who are creating or modifying 
user permissions may work only at the aggregate permission 
level, not at the individual application permission level. A 
user profile is defined by one or more selected aggregate 
permissions, and the users only need to know how to select 
aggregate permissions for users. A user who has a relation- 
ship manager responsibility will dispense that responsibility 
at the aggregate permission level. 

Each aggregate permission is given a name that describes, 
for example, a form of business function, usually in the 
context of the portal application that defines that permission. 
Portal application permissions that need to be accessible to 
someone whose role is to fulfill the business function are 
enabled with (he perform aspect of the aggregate permission. 

Certain portal applications that may be considered critical 
services are always enabled for every portal user. This can 
be done by providing a mechanism to enable permissions of 
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those applications without use of the aggregate permissions 
model and without requiring user action. 

Setting the perform or grant rights of an aggregate per- 
mission is equivalent to setting those rights for all of the 
constituent fundamental permissions. 

Aggregate permission definitions are stored in an aggre- 
gate permission database table. The table is initialized wheo 
a portal-providing company's portal is installed, but unlike 
fundamental permissions, aggregate permission definitions 
can be modified without any corresponding change in appli- 
cations that rely on the permissions that are part of the 
aggregate permission. However, the definitions are not 
modified after the portal is installed. Aggregate permissions 
make it easier to modify the configuration portion of an 
application without modifying the underlying application 
functionality. For example, new aggregate mappings can be 
installed in the database, and new screens can be created to 
set these aggregates, all without changing the application 
code that consults fundamental permissions to see what 
actions are allowable. Nevertheless, all of these definitions 
are put in place before a portal is installed. 

EXAMPLE OF AGGREGATE PERMISSIONS 
Assume that the fundamental permissions include: 
Create Company, argument is company type. User can 

create companies of the specified types. 
Modify Company, argument is company. User can modify 

the profiles of the specified companies. 
Delete Company, argument is company. User can delete 

the profiles of the specified companies. 
Create Company Users, argument is company. User can 

create users at the specified companies. 
Modify Company Users, argument is company. User can 
modify the profiles of users at the specified companies. 
Delete Company Users, argument is company. User can 
delete the profiles of users at the specified companies. 
Assume that the aggregate permissions include: 

Company Creator, argument is company type. Maps to 

Create Company and functions the same way. 
Company Manager, argument is company. Maps to 
Modify Company, Delete Company, Create Com- 
pany Users, Modify Company Users, and Delete 
Company Users. User can modify and delete com- 
pany profiles, and create, modify and delete users 
profiles at the specified companies. 
Company User Manager, argument is company. Maps 
to Create Company Users, Modify Company Users, 
and Delete Company Users. User can create, modify 
and delete users at specified companies. 
Assume that the system administrator and company have 
perform and grant permission for all values of Company 
Creator aggregate. 

When the system administrator creates company A, he 
automatically becomes the Company Manager and Com- 
pany User Manager of company A. He gives company A 
perform and grant rights to the Company Manager and 
Company User Manager aggregate permissions for com- 
pany A All users at company A now have (he potential to 
manage the company profile and the profile of all users at the 
company. 

If system administrator creates user B at company A and 
gives him the full set of permissions allowed to company A, 
user B can manage the company profile, and create and 
manage all user profiles at the company, but he cannot create 
any new companies. 
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If user B creates user C at company A and gives her for example, to their roles in a commercial supply chain, and 

perform rights to the Company User Manager aggregate each user can be defined as having only a specified role 

permission for company A, then user C can create and within the company to which he belongs. For example, the 

manage the profiles of all users at company A, but cannot company types could include sales representatives ("reps") 

manage the company profile itself, and cannot give anyone 5 and suppliers who are represented by the manufacturers 

else the right to manage user profiles at the company. ("principals"). Within a rep company, a user could have a 

role as, for example, an outside sales rep, an inside sales rep, 

USER PREFERENCES Q r a rep manager. Within a principal company, a user could 

A user's profile includes preferences, which capture bow *™ » role as a product manager or national sales manager, 

the user wants to set up his personal relationship portal and 10 for oXam P le - 

to receive information. Tbe preferences that are available to Relationships may be defined between parties of specified 

a user are limited by the user's permissions. l yP<* *n d between individuals having specified roles in 

A portal application may specify preferences that gener- ""P"** J* example a product manager of a 

ally control bow a feature will operate within the portal „ ^P^' may have a relaUonsh.p with a sales representative 

application, provided the user has the permission to use mat 15 «* » vendor f b « l »»* * ^'fTf^ i 

feature. An example of a preference is a selection of seven o{ ,he And individuals who belong to a 

of ten available news channels to be displayed in a news ^f'!™* h k , , ? f 7 

application. The permission is the ability of the user to kmd wU, any mdividuals who belong to ^thersuppher. In 

access the news application; the preference is what news add ^, n to compan.es and mdmduals the system can 

20 control relationships between groups of individuals, for 

sources will be displayed. . .. 57 e t- - v * — v a 

\ .... ■ , example, the client team for client X in company Y and a 

Preferences are only associated with users, not with ^ ^iew team for vendor Y in client X. 

companies, because preferences are more closely related to relationships can be used to govern the ability of the 

how a user makes use of a user portaL . . , , r . . * , 

^ n r individuals, groups, and companies to access and use con- 
Preferences are specific to one user only. Preferences 25 tent and features maintained on a relationship server, 
cannot be cascaded When a user is granted permission to mc contcQi ^ ^ bc ^ 
access a portal application, the application automatically ^ m a ^ . lemcnUtion m a ncw F bu siness 
gives the user access to all relevant preferences. application used to manage and track new business 

For example, suppose that preferences "sort order" and opportunities, requests for samples, action item tracking, 

"filter by" pertain to view and modify permissions of a 30 clcctronic discussions, registration of companies and users 

particular portal application and that the preference "confirm by mc ^^g up of profiles, an address book, and admin- 

before delete" pertains to the "remove" permission for that istrator functions that enable a designated administrator for 

portal application. If a user does not have access to the a g vcn comply to control the creation and maintenance of 

"remove" permission, when the preferences page is gener- ^ pro files ^6 relationships and a designated system 

ated for a user, the portal application is coded not to display 35 ^ inistra tor for the portal-providing company of the server 

the "confirm before delete" preference. - l0 contro i mc creation and maintenance of company profiics. 

When a user is initially created, bis preferences will j^e user interface that is presented through a browser to 

default to a standard setting, regardless of tbe user type or a g i vcn us er depends on the user's role, on user and company 

company. Unless the user performing the user creation or profiles, and on definitions of relationships between 

modification purposely chooses to modify the user's individuals, groups, and companies. Among the facilities 

preferences, the preferences remain in the default state. provided on various user interfaces are the ability to invite 

Preference templates simplify the process of configuring participation by users at other companies with which the 

a user's preferences. A preference template specifies the company to which a user belongs has a relationship, to 

settings for a number of individual preferences. When a 45 create a document, to manage (create, view, modify, and 

preference template is applied to a user, all of tbe user delete) commercial opportunities, to manage (create, view, 

preferences are set as specified in the template. Preference modify, and delete) requests, to manage (create, view, 

templates can be applied by users to their own profiics, or modify, and delete) action items, to manage (create, view, 

they can be applied by a user's profile manager to that user's modify, and delete) address books, and to control user 

profile on his or her behalf. SQ preferences. 

Preference definitions are recorded in a table in the portal A company administrator also has user interface access to 

management database that includes, in one implementation, facilities for approving new users, approving new 

the name of the preference, a label for the preference, a flag relationships, managing relationships, requesting 

indicating whether it accepts single or multiple values, a relationships, altering a company profile, and viewing users, 

type code indicating whether the value is accepted as an 55 The overall system administrator is provided with user 

input field, list, or set of choices, one or more default values interface access to the ability to view companies and users, 

for the preference, a set of values for the list elements or For each function, each role of a user, and each company 

choices, an optional set of labels for the list elements or type to which the user belongs, the system defines permis- 

choices, and an optional set of default values for the list or s i 0 ns that determine whether a user having that role can 

choices (one value for an input field). w access that function. The user interface is constructed to 

Actual preference values are stored in another database enforce the defined permissions, 

table in the portal management database. The relationships between companies and between users 

ruriPP1TInifP ~„ are enforced by the implementation of the user interface 

RELATIONSHIP MANAGEMENT 65 a user does not have permission to view a specific company 

In another implementation approach, companies may be or a specific user, then the various lists and other interface 

defined as belonging only to specified types that correspond, elements that display to the first user companies and users 
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with which he can interact will not include the non- 
permitted parties. In effect, the first user wilt have no way to 
know that the non-permitted parties cveo exist let alone any 
way to interact with them through the system. Thus, the user 
interface regulates and implements the permitted relation- 
ships for each user and company automatically based on the 
stored permissions. 

Relationships are established as follows. 

A new company may initiate a registration by providing 
appropriate fields of information for a profile through the 
user interface presented by the browser. The system admin- 
istrator will review the information and either approve or 
disapprove the registration. The user who initiated the 
registration process for the company becomes the company 
administrator. 

A user profile for a registered company is also created 
through the user interface presented by the browser. After 
the new user initiates the registration process by entering 
information needed for his profile, the record is presented to 
the company administrator who can approve or disapprove 
it. 

Because the company profile and the user profile define 
the company type and the role of the user, the permissions 
applicable to such companies and users can be used to 
regulate the relationships. For example, the permissions may 
provide that a national sales representative of a rep firm can 
have a relationship with a product manager of a principal 
company with which his company has a relationship. Then, 
when a new product manager is added to a principal 
company, the new product manager automatically acquires 
the relationship permissions associated with new product 
managers of principal companies. The role that a user has 
within a company is controlled by the company administra- 
tor. 

Setting up a relationship between one company and 
another (or between other parlies such as individual users or 
groups) is initiated by the one company or party requesting 
the relationship with the other. The company administrator 
of the other company is presented with the request and 



the relationship is recorded on the system. As part of the 
approval process, the administrator is able to view a list of 
users who have certain roles for the company seeking the 
relationship. In a variation on this implementation, each 
party is assigned a "key" (a code sequence known only to 
authorized users). Any user who knows the key can use it to 
establish a relationship with the party to which the key 
applies. Transmittal of the key occurs through means outside 
of the portal. In this way, users that have an existing (or 
desired) business relationship can establish a portal relation- 
ship before they arc able to use the portal as a communica- 
tion mechanism between them. 

In another implementation, the permission to establish a 
relationship between companies (or other parties such as 
individual users or groups) belongs to any user who is a 
manager of both the parties that will be involved in the 
relationship. In this case, parties cannot initiate the relation- 
ship building process themselves; it requires a third party. 

The effects of the relationships between users and com- 
panies are determined by the types of companies and the 60 
roles that the individuals play in those companies. Permis- 
sions are applied automatically through relationship defini- 
tions. For example, a chain of people may have a relation- 
ship with respect to assembling and delivering content, for 
example, a product brochure. The same people may have no 
other relationship to one another with respect to a different 
set of activities. 
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Permissions can be driven based on attributes of a rela- 
tionship. If each user's profile is defined to include demo- 
graphic attributes such as geographical location, the right to 
see highly confidential information, and existing relation- 
ships with specified other parties, then another party can 
specify, for example, that he wishes to permit users who 
have certain demographic characteristics to receive a certain 
piece of marketing literature. In such a system, the relation- 
ships need not be governed by predefined roles, or by 
companies or groups to whom the users belong, or by 
pre-specified permissible relationships. 

Other embodiments are also within the scope of the 
following claims. For example, the mechanism by which the 
user interacts with the system need not be a web browser. 
The user interaction can be governed by devices other than 
a web server. The parties who make use of the system need 
not be companies and their employees, but could be any 
entities and individuals who "belong" to them. The context 
in which the invention is implemented need not be based on 
business relationships, but could be based on any relation- 
ships that entities may wish to regulate. 

Appendix A 



Component 



Type 



Description 



AggrcgateEIcmcnt 



AggregptoEJement 



Database table 



Java class 



AggrcgptcPtrmisaion Database table 
AggregptePermiesion Java class 





Aggregate Value 
Aggregate Value 


COM object 
Java class 




PartyPermission 


Database table 


40 


Pa rlyP reference 


Database table 




Part yP reference 


Java class 




PermisaionValue 


Java class 


45 


PortalPermission 


Database table 




Porta IP enniii Ion 


Java class 




Porta IP reference 


Database table 


50 


PortalPrcfcrcnce 


Java clasa 




PreferenceCboice 


Java ctaas 




PreferonceDisplay 


Java class 


55 


PreferenceMa nager 


Java class 



Contains mappings between 
aggregate and fundamental 
permissions 

Manages the fundamental 
permissions associated 
with an aggregate permission 
Contains aggregate permission 
definitions 

Manages data associated with 

aggregate permission definitions 

COM wrapper for business logic 

Manages setting aggregate and 

fundamental permission values 

Relates Party objects to a set of 

permiwion values 

Relates Party objects to a set of 

preference values 

Manages data associated with 

preference values 

Retrieves individual permission 

values 

Contains application permission 
definitions 

Manages data associated with 
permission definitions 
Contains application preference 
definitions 

Manages data associated with 
preference definitions 
Manages data associated with 
preference choices 
Formats permissions into XML 
for display 

Manages the Interaction between 
preference defaults and values 



Appendix B 



Screen Name 



Screen Description 



Start Menu: This is actually not a screen but a component of the 

"My Prefeiencea" Start Mena This is the component that an end-user 
uses to access persona lizatloo features such as 
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-continued 



•continued 



Screen Name 



Screen Description 



preference settings and access to demographic 

information contained in his/her profile. 

Thii is actually not a (croon but a component of the 

Start Menu. This is the component that contains 

administrative features such as access to company 

and user profiles, sending password 

reminders, and managing templates. 

This is an implementation of a standard selection 

screen. It allows a user to examine the full list 

of users s/he may access and select one for 

modification, removal, or choose to create a new 



SUrt Menu: 
"Portal Builder- 



Select User 



Common User 
Demographics 

Job Function 
Additional Data 
Collect 

Select Aggregate 
Permissions 
(user profile) 
Application & 
Permission On-line 
Report 
Configure 
Application 
Preferences 

User Managers 



Company Select 



Common Company 
Demographics 
Company Type 
Additional Data 
Collect 

Select Aggregate 
Permissions 
(company profile) 
Company 
Organization 



Company Managers 



Company Profile 
Completed 



Password Reminder 



A data collection screen that every portal user is 
required to fill out This is also the screen that 
allows the portal password to be set and changed 
This screen containss s dynamic selection of data 
elements depending on the Job Function^) selected 
for a user. The purpose of the screen is to capture 
data elements unique to the Function the user plays. 
This screen displays all aggregate permissions the 
user being modified may be given access to. 

This screen displays to the user what applications 
and permissions are available to the user as a 
result of the selected aggregate permissions. 
Allows for the configuration of application 
preferences. Only those applications to which the 
user has permission to use will be available for 
preference setting. 
This screen appears as part of user 
creation/modification and is used to identify 
what other portal users may update this user's 
profile. 

This is an implementation of a standard selection 
screen. It allows a user to examine the full list 
of companies s/he may access and select one for 
modification, removal, or choose to create a 
new company. 

A data collection screen that every portal company 

will be required to fill out 

If additional data is necessary based on the 

Company Type selected, this screen is generated 

to collect those elements. 

This screen allows for the selection of aggregate 

permissions. These permissions define what this 

user may do in the portal environment. 

This screen allows a company to define its internal 

organization (e.g. regions, branches, offices, etc.) 

This information is used as sn attribute of each user 

and might be leveraged by porta) applications. 

This screen appears as part of company creation/ 

modification and is used to identify what other 

portal users may update this company's profile. 

This screen marks the end of a company profile 

creation or modification. Options exist here to 

determine how users at that company should be 

affected. 

Using the standard user selection screen, this form 
allows users to be selected and an e-mail sent to 
their e-mail address on file with a password 
reminder. 



Appendix C 



Argument 



Description 



Create Company Type Company Type Create companies of the 

specified type 

View Compauy Type Company Type View companies of the 

specified type 

Modify Company Company Type Modify companies of the 
Type specified type 





Permission 


Argument 


Description 


5 


Delete Company Typo 


Company Type 


Delete companies of the 












View Company 


Company 


View specified company 




Modify Company 


Company 


Modify specified company 




Delete Company 


Company 


Delete specified company 




Create Company 


Company 


Create users at specified 


10 


User 




company 




View Company User 


Company 


View users at specified company 




Modify Company User 


Company 


Modify users at specified 








company 




Delete Company User 


Company 


Delete users at specified 








company 


15 


View User 


User 


View specified user 


Modify User 


User 


Modify specified user 




Delete User 


User 


Delete specified user 
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What is claimed is: 

1. A method comprising 

making at least one digital facility available via an elec- 
tronic communication medium, 
storing information that reflects the existence of relation- 
ships between identified parties with respect to use of 
the digital facility, 
storing information that reflects preferences of the iden- 
tified parties, and 
permitting a predetermined type of interaction of the 
parties via the electronic communication medium with 
respect to the digital facility based on the stored infor- 
mation that reflects the preferences of the identified 
parties and the stored information that reflects the 
existence of the relationships between the identified 
parties. 

2. The method of claim 1 in which the stored information 
identifies the nature of interaction permitted or precluded 
between identified parties with respect to use of the digital 
facility. 

3. The method of claim 2 in which the nature of interac- 
40 tion includes one of the parties being exposed to the exist- 
ence of another of the parties in connection with using the 
digital facility. 

4. The method of claim 3 in which the existence of the 
other of the parties is made apparent by inclusion of the 

45 other of the parties in a displayed list of parties with whom 
interaction is permitted, the displayed list being determined 
by the stored relationship information. 

5. The method of claim 1 in which permitting the inter- 
action of parties via the electronic communication medium 

50 is governed by permissions defined with respect to the 
relationships. 

6. The method of claim 5 in which the permissions include 
a permission to be aware of the existence of specified other 
parties. 

7. The method of claim 1 in which the parties comprise 
individuals. 

8. The method of claim 1 in which toe parties comprise 
groups of individuals. 

9. The method of claim 1 in which the parties comprise 
commercial enterprises. 

10. The method of claim 1 in which the permitted 
interaction includes working together on a task. 

11. The method of claim 1 in which the permitted inter- 
action includes delivery of content. 

12. The method of claim 1 in which the permitted 
interaction includes one party accessing specified data that is 
associated with another one of the parties. 
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13 . The method of claim 1 in which individuals may have sions and the aggregate permissions associated with the 
a relationship only if respective institutions with which they given application. 

are affiliated have a relationship. 20. The apparatus of claim 18, wherein the plurality of 

14. The method of claim 1 in which the parties comprise fundamental permissions further comprises a perform per- 
commercial entities belonging to different levels of a supply 5 mission to permit a member to perform at least a portion of 
chain. one of the applications. 

15. The method of claim 1 in which the parties comprise 21. The apparatus of claim 20, wherein the plurality of 
groups of individuals and the relationships include relation- aggregate permissions further comprises a grant permission 
ships between two of the groups or between a group and the to pefmit a memDer to gran ( a permission to one or more first 
company. 10 members. 

16. The method of claim 1 in which the stored information %l ^ apparatus of cUim 2 0, wherein the plurality of 
is created and controlled by parties only in accordance with permissions further comprises a grant permission 
permissions betonging to those parties. .... to permit a member to grant a perform permission to a 

17. The method of claim 1 in which the P^termmcd P on ^* mtmb £ excluding the granting 
types of interactions that arc permitted and precluded are 15 membef 

defined in stored permissions. m 23 ^ apparams of claim 18> wherein me plurality of 

18. An apparatus comprising: fundamental permissions further comprises permissions to 
a plurality of applications; permit a member to create or modify the first group profile 
a portal management database comprising or to create or modify another first member profile. 

a plurality of fundamental permissions, 24. The apparatus of claim 18, each first group member 

a plurality of aggregate permissions, each aggregate profile to include a list of preferences related to the first 

permission including one or more fundamental group member. 

permissions, each aggregate permission associated 25. The apparatus of claim 18, the portal management 

with one of the applications, database further comprising a second group profile for a 

a first group profile for a first group, the first group second group, 

profile including a plurality of first group perm is- 26. The apparatus of claim 25, the portal management 

sions based on a mapping of the aggregate permis- database further comprising a plurality of second group 

sions with the first group, member profiles for a plurality of second group members, 

a plurality of first group member profiles for a plurality ^ the second group profile to include a plurality of second 

of first group members, each first group member group permissions and a plurality of second group member 

profile including a plurality of first group member relationships, each second group member relationship to 

permissions based on a mapping of the plurality of relate one of the second group permissions to one or more 

first group permissions with the first group member. second group members. 

19. The apparatus of claim 18, further comprising: ^ 27. The apparatus of claim 25, the first group profile to 
a plurality of personal relationship portals, each personal further include a first group relationship to relate one of the 

relationship portal to provide one of the first group first group permissions to the second group, 
members with access to at least a portion of a given 

application based on the first group member permis- ***** 
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